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FOREWORD 


This document was developed as part of the Integrated 
Programs for Aerospace-Vehicle Design (IPAD) program documentation 
in accordance wth contract NAS1-74700 . Other closely related IPAD 
documents are: 


NASA CR 2981 
NASA CR 2982 

NASA CR 2984 

NASA CR 2985 


Reference Design Process (D6 -IPAD-700 10-D) 

Product Manufacture Interactions With the 
Design Process (D6-IPAD-7001 1-D) 

Integrated Information Processing 
Requirements (D6 -IPAD-700 12-D) 

IPAD User Requirements (D6-IPAD-7Q0 1 3— D) 


The NASA Langley Research Center Document Coordinator for 
this document was David D. Loendorf . 


Measurements included in this document were not generated on 
the IPAD program; therefore, they are shown here in U. S. 
customary units. A conversion table (U. S. to S. I.) is included 
in appendix B. 


-in- 



DISCLAIMER 


By acceptance of and in consideration of the receipt of this 
document , data, or software, produced by The Boeing Company 
(Boeing) under National Aeronautics and Space Administration 
(NASA) developmental Contract No. NAS1-14700 (IPAD) , the third 
party recipient, its successors and assigns agree as follows: 

THAT THE THIRD PARTY RECIPIENT, ITS SUCCESSORS AND ASSIGNS 
SHALL HAVE NO RIGHT, REMEDY OR CLAIM AGAINST BOEING AND THAT 
BOEING SHALL NOT HAVE ANY OBLIGATION OR LIABILITY OF ANY 
KIND, INCLUDING WARRANTY, EXPRESS OR IMPLIED, OR TORT, 
INCLUDING NEGLIGENCE, ARISING OUT OF THE RECEIPT, POSSESSION, 
OR USE IN ANY WAY OF THIS DOCUMENT, DATA, OR SOFTWARE BY THE 
THIRD PARTY RECIPIENT, ITS SUCCESSORS, AND ASSIGNS. 
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1.0 SIMMARY 


Engineering projects such as aircraft, spacecraft, etc., are 
organized as product programs. The program serves to integrate 
functional departments such as marketing, finance, engineering, 
and manufacturing. This document describes the management systems 
used to integrate or interface functional elements of the program. 

The basis for technical direction consists of the work 
breakdown structure (WBS) and design-to-cost functions. The WBS 
is a structured index of the end products to be produced by the 
program. It promotes understanding of all tasks and provides a 
mechanism for cost collection. It subdivides the program into 
manageable work areas and includes a numbering system to relate 
functional aspects to control media. The design-to-cost functions 
acknowledge program controls emphasizing cost as a dominant factor 
in system and hardware design. A design-to-cost board has 
responsibility for design-to-cost implementation. Work package 
teams are organized to accomplish the elements identified in the 
WBS. Trade studies are evaluated for cost effects cn baseline 
target costs. Monitoring and control features based on the WBS 
provide periodic audit type comparisons of target costs to the 
current predicted costs for each WBS element and are ‘"rolled up” 
to identify total program costs. Life-cycle costs and post- 
development objectives are considered prior to design release. 

A baseline master schedule is used with control based on a 
hierarchy of tiered schedules aligned to the WBS, including both 
"work-oriented" and "milestone-oriented" schedules. Reporting 
provides a centralized source of schedule status and milestones. 

The WBS is used to plan, control, and report budgets, costs, 
schedules, and performance. 

Product configuration management consists of configuration 
definition and identification (usually of a baseline) and the 
change controls required to effectively iterate the baseline to 
the final product (s) . 

Policy establishes responsibilities for business, 
engineering, and manufacturing data processing systems. Data 
administration is recommended. 

Engineering schedule and budget tracking is based op a 
central source of schedule and job status. 

Management information is a combination of automated and 
manual displays presented in a visibility room. 



2.0 INTRODUCTION 


This document gives a brief description of management systems 
used to direct and control a product -oriented program. Figure 1 
illustrates the relationship of the document to other task 1 
documents. Figure 2 shows relationships of the various management 
tools. The primary elements of technical direction consist of the 
work breakdown structure (WBS) and the design- to-cost procedures 
adopted for the product program. The development of a WBS and the 
implementation of Design-to-Cost are discussed in section 4.0. 
Schedule management, including controls and reporting, is 
discussed in section 5.0. Resource management, including controls 
and reporting, is discussed in section 6.0. Product configuration 
management during all phases of the product program is discussed 
in section 7.0. Data management is discussed in section 8.0 in 
terms of data processing policy and data administration. 

Accounting systems to track engineering schedule and budget 
performance are discussed in section 9.0. Visibility and display 
of management information are discussed in section 10.0. 

Use of commercial products or names of manufacturers of this 
report does not constitute official endorsement of such products 
or manufacturers, either expressed or implied, by the National 
Aeronautics and Space Administration. 
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3.0 ABBREVIATIONS 


ADJ 

BUD 

CAE 

CO 

COMPL 

COMTD 

CUM EXP 

DDM 

DTCR 

EAC 

ECP 

EXC 

EXP 

FCST REM 

IPAD 

JS 

M 

PB 

PD 

PE 

PS 

PIN 

QC 

SCH 

SOW 


Adjusted 
Budgeted 
Calendar (X) 

Change Order 

Completion (current scheduled) 

Completed (original commitment) 

Cumulative expenditures 
Design decision memo 
Design-to-cost report 
Estimate at completion 
Engineering change proposal 
Exception signal 
Expended 

Forecast remaining 

Integrated programs for aerospace-vehicle design 

Job status 

Manual 

Past budget (cumulative manmonths) 

Preliminary design 

Past expenditures (cumulative raanmonths) 

Past manning schedule (cumulative manmonths) 
Program item number 
Quality control 
Schedule 

Statement of work 



SRC 

SSD 

TE 

TSR 

WBS 


Special requirements code 
Status source document 
Trailing edge 
Trade study request 
Work breakdown structure 


6 



4.0 TECHNICAL DIRECTION 


This section delineates the prime management tools used to 
identify and direct all program work items. 


4.1. WORK BREAKDOWN STRUCTURE (WBS) 

A program work breakdown structure is a product-oriented 
family tree composed of elements that result from program efforts 
during the development and production of a product. A WBS is a 
structured index of the product (s) to be developed or produced and 
relates the elements of work to be accomplished to each other and 
to the end product (s) and provides a common denominator against 
which all planning, scheduling, costing, and accomplishments are 
related . 

It is developed downward by proceeding from the definition of 
the program/project objective through successive levels to the 
lowest level of detail required for effective program planning, 
control, and support. 


4.1.1 WBS PURPOSE t 

The WBS is used as the forcing function to establish 
standardized nomenclature, definition, and orderly arrangement of 
all major elements (hardware, software, services, data, etc.) and 
in planning for allocations, estimates, actions, and work 
execution. The reporting of progress, performance, and 
evaluations shall be based on the WBS. 

The WBS serves as a prime management tool, starting in 
Engineering and encompassing all program disciplines: engineering, 
operations, business management, customer relations, etc. WBS is 
used to plan, control, and report: 

Budgets — Identified on program control matrix by 
organization, WBS element, and significant work order 

Costs- — Charged, collected, and reported through a charge 
number structured to the significant WBS code 

Schedules — By WBS element and code number 

Performance — Tracked and reported by organization, WBS 
element, and WBS code 
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4.1.2 WBS DEVELOPMENT LOGIC 


Unlike the product design levels (see D6-I PAD- 70010 -D) , the 
complete WBS does not emerge at the beginning of a program. Its 
development evolves through the total product definition phase and 
normally is not totally defined until the detail design phase 
{fig. 3 , WBS development phasing) . 

Levels are used to define the WBS and are described as 
follows: 

Level 1: Total product program 

Level 2: A logical grouping of functional categories of the 

program, i.e., major product hardware elements 
{structure, functional systems, propulsion, and 
power) ; development; management; services; and 
support 

Level 3: Major subdivisions of the level 2 elements, i.e. , 

structure (wing, body, etc.) and test (laboratory, 
flight test, etc.) 

Levels and on are logical subdivisions of the upper- level 
elements. The lower levels of the WBS will vary from program to 
program depending on the company organization, product design 
complexity, configuration management procedures, etc. 


4.1.3 WBS ELEMENT IDENTIFICATION 

Each WBS entry is assigned a unique program item number 
(PIN). The PIN *s are developed with a significant numbering 
system to provide identification of the various program systems. 
(See fig. 6.) 
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Figure 3.—WBS Development Phasing 



The level 1 program element is assigned a three digit program 
identifier. Level 2 elements are assigned individual digits in 
numerical seque nee , i . e . , 

0 = Product integration and assembly 

1 = Structure 

2 = Systems 

3 = Power 

4 = Test development and evaluation 

5 = Management 

The subdivisions of each WBS element at each level are 
assigned individual digits starting with zero for "product 
integration and assembly." It should be noted that there should 
be no more than ten subdivisions for any WBS element at each 
level. This allows for uniform number sequencing and provides 
"roll-up" capability (see fig. 4) . Figure 5 depicts a WBS "tree" 
and shows the identification logic. 

The program item number (PIN) can be the basis for a single 
uniform identification. The following are examples: 

A charge number should contain: 

Type of work — fabrication, minor assembly, engineering 
design, quality control, etc. 

Cost account — Program identifier and WBS levels 2 and 3 
PIN 

Package identifier — levels 4 and 5 PIN 

Type of effort — preliminary design, basic design, 
engineering change proposal (ECP) , test, sustaining, 
etc. 

Performing organization 
Responsible organization 

Manufacturing analysis sheet — The planning sheet identified 

by the PIN for the particular WBS element 

Purchase order — identified by the cost account and package 

number 
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Figure 4.-WBS " Roll-Up " Criteria 





































Detail schedules — identified by PIN of the WBS level being 
scheduled. 

Tool order /tool — identified by drawing number with a tool 
code prefix. The drawing number should contain the 
applicable PIN . 


4.1.4 WBS SIGNIFICANT NUMBERING APPLICATION 

Figure 6 depicts the relationship between various program 
control media. The WBS program item number (PIN) is the base that 
should be in all program systems identifiers. Following are 
examples of identification logic: 

PIN description — a description of the hardware contained in 
the WBS element identified by the PIN 

Work package document — identified fcy the WBS level 4 PIN 

Equipment list — the required standards and purchased 
equipment contained in and identified by the work package PIN 

Engineering drawing — should contain: 

Program identifier 

PIN to at least level 4 

Model 

Random identifiers for the various parts that make up 
that drawing 

Engineering advance material release — identified by program 
identifier and PIN 

Actual costs — collected by cost account and package 
identifier through the cost collection system 

Performance report — rolled up and identified to any WBS 
element by its PIN 
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Figure 6. — 
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4.2 DESIGN-TO-COST 


Design-to-cost, is the establishment of product cost goals 
prior to detail design commitment and tne utilization of 
management disciplines to achieve cost goals through all phases of 
the product life cycle. The design -to- cost effort nust provide 
the manager with data for cost goal assignment. This is 
accomplished through the implementation of discrete work packages 
and work package teams comprising engineering, manufacturing, 
materiel, quality control, finance, and other appropriate 
organizational personnel. These teams produce designs from known 
realistic requirements to ensure accurate, predictable costs 
throughout the product life-cycle. Program controls must 
emphasize cost as an equal factor when product performance and 
schedule decisions are made . 


4.2.1 DESIGN -TO-COST PLAN 

The program design- to-cost plan must apply design-to-cost 
disciplines in all areas of system and product design. The plan 
must ensure that cost is given equal consideration with other 
major design requirements such as performance and schedule. The 
major elements of the plan are described as follows . 


4. 2. 1.1 Policy 

Design-to-cost is the formal acknowledgment of program 
controls which emphasize cost as a dominant factor in system and 
hardware design and serves to drive acquisition and life-cycle 
costs down to their lowest attainable levels. A team approach is 
used to achieve this intent. All necessary functional support is 
given to the design effort. "Design,” as used herein, includes 
all of the steps from system and product conception through 
physical completion and readiness for delivery. 


4.2. 1.2 Design-to-Cost Board 

The program manager has complete responsibility for design- 
to-cost implementation. He selects a design-to-cost manager to 
assist him in this responsibility. The design- to-cost manager 
spends his time working with the functional managers to emphasize 
the importance of the design-to-cost effort. He has the 
responsibility for establishing design-to-cost disciplines and 
chairs a Design-to-Cost Review Board composed of members of 
engineering, manufacturing, materiel, quality control, and finance 
(and other functional organizations that he may deem necessary) . 
The Design-to-Cost Board monitors and reviews the design activity 
and exercises its authority to maintain or drive the cost elements 
so that they can be achieved at or below the cost goals. The 
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Board also selects the principal (both acquisition and ownership) 
cost drivers in the design {historically, 75 percent of cost is 
associated with 25 percent of weapon system components) and 
ensures that particular emphasis is placed on these items . 

Work package teams are responsible for breaking out and 
allocating element cost goals from the total cost goal. Program 
management establishes functional cost goals. 


4.2. 1.3 Work Package Teams 

The design-to-cost manager directs the creation of work 
package teams. These teams are be designated at least down to the 
WBS level 4. Key features of the work package team include: 

Systems, product assurance, design, manufacturing and quality 
engineers, and materiel, located in a common area and 
assigned specific work package responsibility 

Use of a documented design standards plan delineating 
maintainability standards, common tooling philosophies, 
design tolerances, materials, processes, standard hole, and 
thread classes 

Formal participation of manufacturing engineers and product 
assurance personnel beginning with systems and design concept 
and concluding with finite manufacturing and tooling plans 
prior to a producibility engineering approval signature on 
the engineering drawing 

NOTE: Manufacturing and tooling plans for both 

development and production will be written. The 
production plans are used as the basis for the 
refined estimate of the average production unit 
cost. The development planning is released to 
support hardware fabrication. 

Formal approval by quality assurance that inspection 
requirements do not increase costs disproportionately to 
their intrinsic value but meet internal and contractual needs 

The work package teams assist in developing the subdivision 
of the allocated level 4 WBS targets down to the lowest practical 
level, ihe targets are a projection of the average production 
unit cost. This unit is a specifically identified production line 
unit determined by the intersection of the straight-line average 
with the projected learning curve (fig. 7) . 
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The targets or "ceilings*® applied to the system components 
are specified internally by labor standards. These units are more 
constant than dollar-valued or basic factory labor tours and can 
be converted by the application of current basic factory labor or 
dollar factors. Raw material and purchased items have "time- 
locked" or standard dollar targets that can be converted by an 
inflation index to current values. The inflation factor should be 
mutually agreed to by all parties. 

The work package teams ensure that system, concept, and 
initial designs are producible, maintainable, and reparable and 
that manufacturing and inspection methods are incorporated in 
consonance with contractual requirements and company standards. 


4.2. 1.4 Design -to-Cost Application 

Cost targets are shown on cost target sheets which are 
designed so that estimated costs are segregated and trackable 
(fig. 8) . These sheets are compiled for all design items and 
published in a common document. Estimated costs are applied, as 
are the deltas from the target to the estimate. The cost target 
sheets are the t data base for compiling the periodic design-to-cost 
report (DTCR) . At the conclusion of the development program, the 
final cost target document is used to assess and develop the 
design status impact on the design- to-cost goals. 

The estimates and deltas are reviewed and updated by the 
manufacturing and/or materiel members of the work package teams as 
the design develops. These deltas are periodically reviewed 
(usually on a two-week basis) by the Design-to-Cost Review Board. 
Significant upward trends or drifts in the deltas precipitate 
action ranging from informal direction to the release of design 
decision memos (DDM’s) that will effectively freeze the design 
until appropriate corrective measures can be taken. 


4. 2. 1.5 Trade Studies 

The cost targets of recurring and nonrecurring standard hours 
and procurement dollars are the springboard for ini tiating trade 
studies on the development program when evaluation confirms that 
conceptual or preliminary designs cannot be produced at or below 
the baseline (target) cost. 

Trade studies are formally requested via the trade study 
request (TSR) form (fig. 9) initiated by Work package team members 
or the Design/Cost Review Board. 
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Figure 8.— Cost Target Sheet . 







































Trade study request 


Title 

Purpose 

Originator/Group 

Coordinator Phone 

Work statement (describe for each participating group) 


Program 

No. [£> 

Date 

Revision 

Sheet of 


[J>Sequential trade study number 
followed by suffix to indicate 

C — Cost trade 

C/W — Cost/Weight trade 

T — Technical trade 

W — Weight trade 


Data req'd 

□ Engrg (design M/hrs) 

□ Weight (lbs) 

□ O.P. ($) 


O Fab, l&A (Manhours) 

□ Material ($) 

□ P.E. ($) 


O P/N count 

□ Quality 



Est completion date .. 

Study authorized by: 



Recommended disposition 

□ Incorporate □ Cancel 

Project Fngineer/Rtaff Chief 


Engineering management disposition 

□ Incorporate □ DDM required □ Revise config des doc 

□ Cancel O Revise work pkg doc 


Approved: 


Figure 9.— Design-to-Cost Trade Study Request 



Trade studies are categorized as "process trade studies" 
(normally requested by manufacturing) or "design trade studies" 
(normally requested by engineering) and are assigned the following 
order of priority: 

Priority Type 


1 Configuration trade (T) 

1 Cost reduction trade (C) 

2 Weight reduction trade (W) 

3 Cost/weight trade (C/W) 


The flow diagram for arriving at design decisions through the 
use of trade studies is shown by figure 10. The work package 
teams are charged with the responsibility of scrubbing down the 
system, subsystem, or design to meet or better the target cost and 
to resolve minor design-to-cost conflicts without resorting to 
formal trade studies. The iteration process is, however, recorded 
on the cost target sheet as a chronologically adjusted estimate as 
the design crystallizes. Where a cost conflict arises that cannot 
be resolved at the working level, manufacturing members will issue 
a formal trade study request. 


4.2. 1.6 Monitor and Control 

It can be seen from the foregoing that the cost target sheet 
containing the baseline and the current estimate delta is the 
trackable element in the design-to-cost discipline. This is 
depicted graphically by figure 11. 

Summary target and estimate delta data are compiled at WBS 
level 4 and up periodically (usually weekly) during the 
development program for presentation to the Design- to-Cost Manager 
and Review Board. 

The degree of success in achieving design- to-cost is a 
reflection of the effectiveness of the work package team members 
and their line management. In recognition of this, they are 
staffed by experienced engineering and manufacturing personnel. 

Management control and responsibility is vested in the 
design- to- cost manager, who identifies system and subsystem 
requirements that contain potential high-leverage cost elements 
and is the focal point for initiating alternate approaches or 
requirement changes to reduce cost estimates. He establishes a 
design-to-cost area in the program control room that displays 
current system, element, and functional progress in achieving the 
cost goal and that highlights actual and potential problem areas. 
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Figure 11.— Cost Target Development and Audit 
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This is achieved through the use of tracking charts showing the 
current and past estimate against the cost target. 

The continuing iteration of the design by key personnel is 
the cornerstone of the cost-effective design. Their efforts are 
recorded by updated estimates on the cost target sheet. Formal 
iteration by trade study is documented. Each authorized trade 
study is assigned a sequential number and suffix for 
identification within the document which is a permanent record of 
trade study activity. Design-to-cost enforces the cost 
disciplines during the design development phase, which make the 
goals realistic. This premise is illustrated by figure 12. The 
concurrent development of the production tooling and planning with 
the development planning was discussed in section 4 .2.1.3. The 
overall iteration and interplay between the work package teams and 
the Design/Cost Committee is depicted by figure 13. 


4 . 2 . 1 . 7 Life-Cycle Costs 


Cost targets (see sec. 4. 2. 1.4) include life-cycle costs and 
are based on product acquistion cost and product operational 
costs. Although design- to- cost has been primarily discussed 
within the context of reducing the cost of producing the system, 
the thrust of the discipline is inherently toward design 
simplicity such as part count reduction, the elimination of 
ornamental quality, and standardization. However, design 
simplicity is usually synonomous with reduced life- cycle costs and 
should be taken into account throughout all design development 
iterations . 


4. 2. 1.8 Post -Development Programs 

The ultimate objective of design-to-cost is to achieve the 
most cost-effective design prior to design release, which, in 
theory, eliminates any further downstream producibi lity 
application. However, during both preproduction and production 
programs, the estimates made during the development program are 
updated to reflect actual costs and are used to update the 
average production emit target cost. The same remedial measures 
discussed heretofore are applied as design changes are incurred. 

Similar design-to-cost disciplines are applied to downstream 
design activities such as special tooling and special test 
equipment. 
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Figure 1 3.— Design-to-Cost Flow Control (Development Program) 













4.2.2 DESIGN WORK PACKAGES 


The design work, package is an efficient tool to quickly 
acquaint the personnel assigned to the task with the task to be 
accomplished and with the applicable design requirements. It also 
provides early visibility of the component design approach and 
gives technology and manufacturing specialists an opportunity to 
make suggestions for cost and weight improvements. 

The total product hardware is subdivided into discrete 
packages at WBS levels 4 and 5, and is organized as volumes of a 
document. Each volume is identified by the significant WBS code 
(sec. 4.1). The work packages will define the hardware, schedule, 
and critical events and will establish targets for the designer. 
Their purpose is to provide basic information for the design, 
development, and manufacture of the product and to serve as prime 
tools for: 

Developing the complete component (element design) 

Identifying potential product improvements including cost 
reduction 

An up-to-date “design description 

Visibility of concept 

Establishing and tracking targets 

Providing up-to-date design review data 

A tool for verification of compliance with design 
requirements and targets for each component design approach 
before detail design layout and drawing preparation 


4.2.2. 1 Work Package Content 

Figure 14 portrays an overview of the design work package 
content and the program data from which the package is derived. 

The following are examples of work package content: 

Design Requirements — An extract of the requirements for the 
particular WBS element from the total program design 
requirements and objectives 

Design Guides — This section will include guides applicable to 
the work package based on historical experiences, such as 
structural durability handbooks, CAD indices, etc. 
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COMPONENT WORK 
PACKAGE DATA (LEVEL 5) 

• DESIGN REQUIREMENTS 

• DESIGN GUIDES 

• HARDWARE DESCRIPTION 

• DESIGN DEVELOPMENT ITEMS 
•TARGETS 

•COST 

• WEIGHT (AN) 

• RELIABILITY/ 
MAINTAINABILITY 

• PERFORMANCE 

• PLANS 

• ENGINEERING 

• MANUFACTURING 


Figure 14. -Design Work Package Data 




Hardware Descriptions — This section is a detailed description 
of the work package hardware and is the baseline description 
for trade studies. It consists of: 

PIN Descriptions — detailed descriptions to the package 
WBS level and lower. (Figure 15 is an example of PIN 
description.) 

Key Layouts — layouts, sketches and schedules, center- 
line diagrams, structural diagrams, etc. 

Interface Requirements. 

Design Development Items — This section is used to identify: 
Unproven design concepts, materials, etc. 

All tests to be conducted to arrive at a design decision 
Special mockup requirements 

Top priority items and plans and procedures for 
accomplishing these special attention items 

Unique materials, processes, etc. 

Targets — The section contains the targets and estimates per 
format (fig. 16) . Weight, reliability, and maintainability 
targets are also included in this section. 

Plans — This section contains the engineering plans and the 
manuf acturing plan for first article. 


4.2.3 WORK PACKAGE TEAM 

The team is a dedicated group responsible for the contents of 
the work package. Members represent engineering (project and 
staff), manufacturing, materiel, and finance organizations. It is 
essential to success that team members be identified who will have 
the '•doing" responsibilities. During the design phase, the 
project engineering member assumes the role of work package 
manager. After completion of design, the role is transferred to 
the manufacturing engineer. Figure 2 .2.3- 1 depicts the team 
makeup for several work packages. Section 4.2.1 (Design -to -Cost 
Plan) delineates the duties of the team. 
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Title: FRONT SPAR INST. - WING BOX 


PIN 

Sh Lof 


MATERIAL 

Ext 

SBT 

Std 

Other 


PARTS AND MATERIAL DESCRIPTION 

Chords: For middle spar, segment will be angle extrusions machined 100% with 

constant flange angle for 423 in. length. Outboard segment chords will be 
angle extrusions machined 100% with flange angle varying throughout 
length of 570 ft. Chord material will be 7075-T73 (upper) and 2024-T2 (lower). 

Webs: Will be broken into approximately 9 pieces, each of which will be constant gage 

2024-T3. Total length = 1563 in. with width varying from 29 in. inboard to 
7.0 in. at tip. 

Doublers: Constant-gage doublers will be riveted to web at cutouts, etc. 

Stiffeners: Approximately 181 extruded "Z” stiffeners will be used between inspar ribs 

and approximately 56 extruded "T” stiffeners will be used at inspar rib locations. 


PART TYPE PART CARD QUANTITY 

Sheet Metal 

Machined 

Cast & Forg. 

Assy. & instl. 

Purchased 

Other 


Fittings: Will be 7075-T73 hogouts with 

engine beam support fittings, 
per LO-953-W-050. 

Note: 80% of all stiffeners are symmetrical. 

ASSEMBLY AND INSTALLATION 


Varies from 
Hh .18 to .30 




The front spar is 1563 in. long and is made up of three segments. The middle segment is 423 in. 
long and has a constant depth of 29.2 in. It consists of 2 chords, web (3 pieces), 53 stiffeners, 
and 8 engine beam support fittings. The outboard segments are 570 in. long varying in depth 
from 29.2 in. inboard to 9.0 in. at tip and each consists of 2 chords, web (3 pieces), and 90 
stiffeners. Spar will be assembled to panels by riveting with 3/16, 1/4, 5/16 and 3/8 dia. rivets 
from b.l. 211 to b.l. 632, spar will be sealed as an integral fuel tank. 



Figure 1 5.— Program Item Description 
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Figure 16.— Design Plan Resource (Budget/Actual) 
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Figure 17.— Work Package Teams 



4.2.4 PRODUCT COST CONTROL 


Since up to 80 percent of a program cost is coirmitted before 
first detail drawing release, it is mandatory that a credible cost 
targeting , estimating, and tracking systems be implemented early in 
a program. The cost system described in this section is based on 
detail-estimating the hardware costs of designs of functional 
components of the airplane at WBS level 5 and lower. Verification 
of these estimates is then accomplished by comparing them to costs 
of components for which good hardware cost, operating costs, and 
performance history are available. 

Cost surveillance and reduction is a continuous process. The 
cost data estimated by feature are adapted to an organization 
accounting system to assign cost targets to each engineering, 
manufacturing, and materiel organization that contributes to the 
end item cost. Maintainability and reliability are targeted and 
tracked in much the same manner. All these, together with 
budgets, are arranged in the work breakdown structure to roll up 
from WBS level 5 (spars, wing, TE flaps, etc.) thus providing a 
very simple responsive audit system (fig- 18) . It is expected 
that program management hardware cost reviews will be conducted 
monthly and budget reviews weekly. 

4.2.4 . 1 Definitions 

Parametric Estimate — An estimate is made of the "probable 1 ' 
cost of an airplane using gross parametric s, appropriately 
adjusted, based on historical statistics (perf orinance, 
weight, etc.) . 

Class I Es timate — A detail cost estimate is made of what the 
airplane "should" cost, based on preliminary hardware 
descriptions to the work package level. Class I estimates 
provide realistic bases for class II targets. 

Class II Estimate — A detailed cost estimate is made of what 
the airplane "should" cost based on refined engineering data 
such as detail layouts and WBS level 5 work package data. It 
is used to verify the hardware cost status as compared to the 
pre-established class II design cost targets. Engineering 
detail "design -to-cost" and manufacturing performance are 
measured against class III cost targets for in-process cost 
visibility . 

Class III Costs — This is the actual hardware costs as 
accumulated by finance, including material, fabrication, 
minor assembly, and major assembly. 
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Figure 18.—WBS: A Single Management Tool 




Probable Cost — This is a parametric estimate of the 
anticipated program cost based on historical relationships 
adjusted for weight , complexity, and commonality. 

11 Should" Cost — This is the calculated value of the hardware 
based on a standard derived from actual experience and 
computed after completion of a series of trade studies . 

4 -2 .4. 2 Cost Model 

Programs costs consist of recurring and nonrecurring hardware 
and program support costs. (See table 1) . 
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Table 1. — Program Cost Model 


RECURRING NONRECURRING 



Production 

Basic engineering (including 


labor; 

component tests) 


Fabrication 

Basic developmental mockup. 


Minor assembly 
Major assembly 

test, and related materials 


Related mat*l. 

Basic tooling and related materials 

HARDWARE 

Quality control 

Basic tool and production planning 

COSTS 

in support of 
prod, labor 

Prod, mat'l. (less static and 
fatigue) 


Porch, equip . 

Purchased equipment 


Direct labor 

Quality cant rol labor in 


fringe benefits 

support of above 


Incremental 

overhead 

Direct labor fringe benefits 



Incremental overhead 


Eng. sustaining 

Engineering administration, 
laboratories, and customer 


Devel. mockup 

support 
Flight test 


Tooling sustain- 
ing plus related 

Major tests, customer support. 

PROGRAM 

materials 

flight test, and related 

SUPPORT 


materials 

COSTS 

Rework, special 
charges » and 

Tool and production planning for 


prod, planning 

static and fatigue testing 


QC labor in 

Production labor and mat *1. for 


support of above 

above 


Purch. equip. 

Purchased equipment development 


develop, costs 

costs 


Engines 

QC labor in support of above 


Buyer-furn equip 

Direct charges 
Fixed overhead 


Direct charges 



Fixed overhead 




4. 2.4.3 Development Sequence 


The development sequence of the design data and cost estimate 
requirements is illustrated in figure 19. 

4. 2. 4. 4 Cost Target Development 

A total program competitive cost is determined, based on 
historical data and market research and analysis. The program 
manager establishes a total program cost target. Dsing historical 
actual costs, he allocates targets to the WBS level 2 elements. 
Each functional discipline, in turn, allocates his targets to at 
least WBS level 5. (See fig. 20.) 

The cost targets are recorded on the cost target tracking 
form (fig. 16) in each work package document (sec. 4.2.2. 1) . 

Detail cost estimates are made and iterated based on the detail 
program item number (PIN) descriptions. 

4 . 2 . 4 . 5 Cost Target Audit Cycle 

Figure 21 depicts the iterative process. An overview of the 
targeting/tracking/cost audit cycle and sequence is shown in 
figures 22 and 23. u 
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Figure 19.— Design Data and Cost Estimate Refinement 
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Figure 21,— Iterative Process 
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Figure 22.— Cost Targeting and Tracking by WBS 
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Figure 23.— Cost Audit Cycle 




5.0 SCHEDULE MANAGEMENT 


A master schedule is used as the baseline for the total 
program. It contains the key milestones and constraints from all 
disciplines , including the customer. The schedule should be based 
on proven experience and should be developed to permit an optimum 
balance between technical and cost performance. Management of the 
schedule acknowledges that variances require compensation in order 
to protect cost and technical objectives. 


5.1 SCHEDULE CONTROL 

Schedule control is based on a hierarchy of tiered schedules 
(fig. 24) , which are generally aligned to work breakdown structure 
(WBS) levels. Tier I is the program master schedule; it covers 
all elements of the program and is approved by all functional 
organizations. Tier II consists of program element schedules. 

They cross functional lines and provide visibility of functional 
schedule integration. Tier II schedules are used to analyze and 
resolve program schedule problems. Tier III and lower schedules 
show functional responsibility. For cost/schedule correlation, 
individual functional schedules are associated with specific 
packages of work having specific budgets. Functional schedules 
aid in the development and substantiation of program schedules. 
They include both "work-oriented" and "milestone-oriented" types. 

The lowest tier is the integrated engineering schedule . It 
identifies and defines the schedule relationships between the 
technical tasks to be performed by the various design project 
groups and the technology staff groups during the basic design 
process. The purpose is to assure schedule integration between 
those tasks which are highly interdependent in terms of technical 
data availability and timely performance of design and technical 
tasks relative to data. Integrated engineering schedules set 
forth the major milestones representing the following schedule 
dependencies z 

Design project group schedule requirements for key interface 
design data from another design project group upon which 
their effort depends 

Design project group schedule requirements for key technical 
data from a technology staff discipline group upon which 
their design effort depends 

Technology staff discipline group schedule requirements for 
key design data from a design project group upon which their 
technical tasks depend 
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PROGRAM CONTROL 


FUNCTIONAL ORGANIZATION 
CONTROL 













Technology staff discipline group schedule requirements for 
key technical data from another technology staff discipline 
group upon which their technical tasks depend 

Effective scheduling of these engineering activities* in 
successive levels of detail as required* substantially increases 
effectiveness of the overall engineering design process. 

Engineering data release dates to support program schedules 
are negotiated between engineering and manufacturing and are 
subsequently input into the data storage and retrieval system. 


5.2 SCHEDULE REPORTING 

The purpose of the engineering schedule reporting system is 

to: 


Provide a centralized source for schedule and status control* 
on a regular cycle, utilizing automatic data processing 
equipment 

Provide total visibility of scheduled engineering milestones 

u 

The schedule reporting requirements and formats are covered 
in section 9.0 "Engineering Performance Reporting.™ 



6.0 RESOURCE MANAGEMENT 


The program manager is responsible for control of program 
funds authorized by company headquarters. During the product 
technical definition phase, he receives from his functional chiefs 
their requirements for resources such as manning, skill mix, and . 
facilities . 


6.1 RESOURCE CONTROL 

The WBS (sec. 4.1) is the tool used to plan, control, and 
report activities such as budgets, costs, schedules, performance, 
facilities, and travel. 

The program manager, with the aid of his functional advisors, 
establishes targets for the major disciplines (engineering, 
manufacturing, materiel, finance, facilities, etc.) based on 
historical information and the requirements inputs. Each 
functional discipline, in turn, allocates his targets to the 
lowest manageable WBS level in his area of responsibility. 


6.2 RESOURCE REPORTING 

During the program, actual expenditures plus estimates to 
complete are collected and rolled up to the program level. These 
are displayed in the visibility room (sec. 10.0) . The estimates 
are compared to the targets and the targets are adjusted as 
required. Figure 25 depicts the process and is similar to the 
original targeting shown in figure 20 . 
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Figure 25.— Resource Control 



7 .0 CONFIGURATION MANAGEMENT 


Configuration management on a program is the continuing 
process by which the configuration of the product is defined and 
controlled throughout its design, manufacture* test* and delivery. 
Configuration management is one of the most important management 
processes used on the program, ensuring that the product 
configuration delivered to the customer represents what he 
contracted for and that the configuration of parts, systems, 
subassemblies, and assemblies are to the desired configuration at 
all steps of production. On a program where the design, 
manufacture, procurement, and test work will be widely dispersed 
among program organizations and subject to complex communication 
channels, effective configuration management is essential. 


7.1 PRINCIPAL CONCEPTS 


7.1.1 CONFIGURATION DEFINITION AND IDENTIFICATION 

This concept involves the management controls which describe 
and identify the product configuration. The controls applied to 
this aspect of configuration management assure that: (1) the 
configuration is defined in accordance with established methods of 
identification, (2) the configuration is documented and officially 
established by management approval, and (3) the configuration 
satisfies the established customer and design requirements, 
including those of Government regulatory agencies. 


7.1.2 CONFIGURATION CHANGE CONTROL 

This concept refers to the systematic evaluation, 
coordination, and approval or disapproval of proposed changes to 
the design and manufacture of the configuration. It is a 
continuing function extending from early design definition 
throughout hardware production. 


7.1.3 PRODUCTION CONFIGURATION ACCOUNTABILITY AND CONTROL 

This concept involves the iranagement controls and paperwork 
systems that carry the intended configuration established by the 
designer forward into the released engineering data, manuf acturing 
data and procurement data so as to reflect the proper hardware and 
software configuration, including authorized changes. 
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7.1.4 PRODUCTION CONFIGURATION VERIFICATION 


Tills concept refers to quality control and procedures that : 
(1) verify the actual "as-built" configurational each production 
unit delivered to a customer and {2} account for completed 
hardware records relative to the configuration H as designed’ 8 by 
engineering and "as planned" by manufacturing engineering. 


7.1.5 INTERFACE MANAGEMENT 

This concept refers to the controls and procedures that 
ensure physical and functional configuration integrity between 
mating hardware elements. This involves configuration 
identification, change control, and verification as applied to the 
physical, functional, and environmental interfaces between work 
package end items assigned to different program organizations for 
design, manufacture, or procurement. The principal applications 
of these procedures occur during design and development, when all 
interfaces must be identified and defined and their configuration 
characteristics must be properly incorporated into the design of 
the mating elements . 


u 

7.2 PRODUCT TECHNICAL DEFINITION PROCESS 

During the product technical definition process, the product 
configuration is developed and defined in accordance with the 
configuration identification requirements. Figure 26 illustrates 
the product technical definition process. This process extends 
through the early program phases, from the conceptual development 
phase and the preliminary design phase to the engineering design 
and development part of the production phase. During each of 
these phases, the engineering design and configuration development 
leads to an appropriate configuration definition represented by 
the required technical documentation, drawings, and data. 

A configuration definition baseline is developed for 
initiating the preliminary design phase. This baseline for 
preliminary design results from the techical concept and 
configuration development work and airline contacts during the 
conceptual development phase . It represents the basic product to 
be offered to the airlines and is defined in the design data 
document and the standard detail specification. It is the 
foundation for the technical and planning work performed during 
the preliminary design phase. 

The second baseline — which is developed for go-ahead — results 
from the further configuration definition, design, and 
marketing/sales activities during the preliminary design phase 
leading to the first customer sale and an engineering detail 
design go-ahead. These activities include establishing the 
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updated standard detail specification; the customer detail 
specification ? which defines the specific airplane purchased; the 
purchased equipment document; the program item number (PIN) 
document; and the work package design specifications which provide 
configuration definition data as part of the work packages. 

This baseline represents the configuration that will be 
developed in detail during the engineering detail design process. 
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Figure 26.— Product Technical Definition Process 























A program go-ahead initiates the production phase. This 
phase consists of the design development* test* and release of 
engineering drawings that comply with specific customer 
contractual requirements. The initial production phase 
configuration is based on the standard detail specification, and 
the customer detail specification resulting from the preliminary 
design phase, as well as the other engineering documentation. 

This configuration is established incrementally by release of 
engineering data within each organization in accordance with the 
program release schedules. 


7.3 CONFIGURATION MANAGEMENT — PRODUCT TECHNICAL 

DEFINITION PHASE 

Figure 27 illustrates the basic flow of conf iguration 
management during product technical definition shown in terms of: 
1) major program milestones, 2) the configuration definition and 
identification activities, and 3) the configuration baseline 
documentation in each case. The time-phased relationships among 
these elements substantially define the functions of configuration 
management during the evolutionary product definition process in 
the early phases of the program. 


7.4 CONFIGURATION CHANGE CONTROL — PRODUCT TECHNICAL 

DEFINITION PHASE 

Figure 28 illustrates the basic concepts of configuration 
change control during the early program phases. The curve in the 
center of the chart illustrates the release of engineering data 
beginning during the conceptual development phase. At this point, 
formal change control is initiated utilizing the configuration 
change control media indicated at the bottom of the chart. 

As the product definition process continues, additional 
documentation is developed and released. The configuration 
identification and definition contained in the baseline 
documentation is subject to an increasing level of configuration 
change control as the definition process continues. Thus, as the 
amount of technical definition documentation released increases, 
the degree of formal configuration change control increases 
proportionately . 
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7.5 CONFIGURATION ACCOUNTABILITY AND 
VERIFICATION — PRODUCTION PHASE 

As engineering configuration data and subsequent design 
changes are released to the manufacturing process, the integrity 
of the configuration will be maintained throughout the engineering 
release function and the downstream functions of manufacturing and 
procurement . 

As the production program progresses through new customer 
introductions — each involving new and different configuration 
requirements — the design, manufacturing, and procurement paper 
systems will accurately reflect the many hardware configuration 
changes between units in the production process . As engineering 
design changes are implemented, additional changes will be 
accounted for in these paper systems to ensure that the hardware 
will be procured or manufactured in the proper configuration for 
each unit. 

The configuration accountability process provides the 
foundation for configuration verification by assuring that the 
design, manufacturing, and procurement paper reflect the proper 
configuration of the hardware. It makes possible the comparison 
and verification of the hardware configurations with the mating 
paper configuration definition. Verification records are required 
at all levels from detail parts to the complete airplane. 

The responsibility for establishing and implementing 
configuration verification procedures, based on established 
configuration accountability systems, rests with organizations 
where the design, manufacture, or procurement responsibilities are 
assigned for each work package. 


7.6 CONFIGURATION CHANGE CONTROL — PRODUCTION PHASE 

There are two purposes for configuration change control 
during the production program. The first is to ensure continuous 
integrity of the design configuration at all stages of 
production — detail parts, subassemblies, major assemblies, and 
complete airplanes. The second purpose is to maintain effective 
management control of program costs and schedules related to 
incorporation of engineering design changes. 

All design changes are implemented at the "doing" 
organization level by change conmitment implementation procedures. 
Some design changes will impact more than one work package and, 
therefore, more than one "doing" organization. Such changes will 
require coordination between the affected "doing" organizations. 
Their commitment and implementation activities must be integrated 
by a Change Commitment Board. Some design changes require 
negotiation and approval by the customer or a governmental 
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regulatory agmcy. All changes will be accomplished in accordance 
with approved procedures . 


Configuration change control procedures are designed to 
ensure that s 1} all program organizations use compatible 
procedures, 2 } control is maintained an design changes, and 3) 
potential downstream impact of a change is coordinated between 
affected work packages and S9 doing fS organizations. 

Figure 29 illustrates time -phasing of engineering changes 
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Figure 29.— Time Phasing of Engineering Changes (Typical Flow) 



8.0 DATA MANAGEMENT 


This section delineates the responsibility for processing , 
storage , and retrieval of data generated by the product program. 


8.1 DATA PROCESSING POLICY 

A corporate policy establishes responsibilities for data 
processing in: 

Business systems used to control or monitor resources applied 
to a program or to functions within the program, e.g., as 
cost and schedule management, configuration definition and 
changes thereto, change control processes, work allocations, 
and assignments. 

Engineering business systems used in direct support of the 
design, planning, ordering, producing, or purchasing and 
accounting for hardware components, e.g., automated parts 
listing release system, and automated wire identification and 
accountability system, etc. 

Engineering scientific systems used to construct geometry 
mathematical models, perform design and analysis, construct 
detail part definitions, etc. 

Manufacturing systems used for material and part inventory, 
numerical control machining, etc. 

A top-down approach should be used to design each system. At 
the top level, the system is described in gross terms to identify 
input and output requirements, in ter functional relationships, and 
interfaces with other organizations. Each succeeding lower level 
describes the processes or functions in greater detail. The 
lowest level contains the individual elements that are applied to 
meet the requirements of higher levels. This approach ensures 
that all required processes are clearly identified and accounted 
for in a cost-effective manner. 

Each system is documented completely to provide continuity of 
system development and implementation, an orderly transition of 
changes in personnel, and schedule or operational compliance . 
Documents are prepared for total system design, operating, and 
maintenance requirements ; user requirements ; and change control 
procedures. These documents establish controls and procedures and 
assign responsibilities for integrity of source data and reporting 
requirements. When the system is implemented, formal change 
control procedures are initiated to ensure that no system 
modification will adversely affect interfacing systems or other 
users of the data. 
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This policy should encourage formal interface between systems 
and make provisions for data administration., 


8.2 DAm administration 

A data administrative function is recommended. The data bank 
administrator (s) is responsible for computer-stored information 
and will design, organize, and implement a data storage and 
retrieval system. Since scientific data processing is technical- 
discipline-oriented, it will be necessary for the data 
administrator (s) to have at least one technical data administrator 
from each engineering group. This person will be responsible for 
the design of the relationships which will be used to store and 
retrieve information unique to that engineering discipline. 



9.0 ENGINEERING PERFORMANCE REPORTING 

Effective planning and control requires a disciplined system 
to provide periodic comparisons of actual and predicted 
engineering performance. Cost and schedule problems requiring 
management attention and action on a timely basis must be 
identified and reviewed on a continuous basis. To effectively meet 
objectives, the reporting system must contain or be interfaced 
with key data. 


9.1 ENGINEERING SCHEDULE TRACKING SYSTEM 
The purpose of the tracking systems is to: 

Provide a centralized source for schedule and status control, 
on a regular cycle, utilizing automatic data processing 
equipment 

Provide engineering organizations with reports that reflect a 
30-day visibility of their scheduled milestones 

All committed engineering milestones should be input into the 
data storage hnd retrieval system with adequate video displays. 
Supplemental weekly reports to the responsible and receiving 
organizations should be made by status source document (SSD) . The 
SSD (fig. 30) is a report showing selected data from the data 
storage and retrieval system, by organization, for all milestones 
due within the next 30 days . It is also the vehicle by which late 
item reports and associated statistical summaries are developed 
for program visibility and problem solutions. 

Each Monday, the work package manager or group supervisor 
should receive an SSD report reflecting a 30 day lock-ahead at his 
scheduled milestones. He should review each listed milestone and 
supply status information as follows: 

a) If the milestone has been or will be accomplished in all 
respects before midnight on Thursday (see "Status to be 
reported as of..." date in the upper right hand comer 
of the SSD page) , enter the completion date in the 
status column followed by an "A" (for accomplished) . 

b) If the SSD milestone is scheduled to occur beyond the 
Thursday "Status to be reported as of..." date, and if 
it is anticipated that it will be accomplished on 
schedule, enter the anticipated accomplishment date in 
the status coluim followed by an "E" (for estimated) 
status code. 
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Figure 30.— Engineering Schedule Status 



c) If it is anticipated that the SSD milestone will not be 
accomplished completely on schedule, enter the new 
estimated completion date or NA (for s, not available”) in 
the status column (followed by an "E B (for "estimated®*) 
status code* Ron arks by the supervisor responsible for 
the milestone, which explain why the release will not be 
accomplished as scheduled, must specifically include 
information in the following three categories: 

REASON: The reason (s) the schedule was not met 

ACTION: The action (s) taken or to be taken, e.g., 

overtime, additional manpower, or coordinating a 
revised schedule with manufacturing/materiel 

CONSEQUENCE: A comprehensive statement assessing 

the impact of a late release on the receiving 
organization and delivery of the end item. The 
reporting supervisor will coordinate with 
manufacturing, materiel, and other 
extemal/intemal affected organizations, as 
required, to develop the consequence statement. 

*• Names of responsible supervisors from affected 
organizations will be included in the statement to 
support upper management review. 

d) If the SSD milestone has been cancelled, enter the date 
of cancellation in the status column followed by an "X” 
(for cancelled) in the space provided for status code, 
with pertinent remarks 

e) If further effort toward the accomplishment of the SSD 
milestone has been suspended pending official 
redirection, enter the date that the effort was stopped 
in the status column followed by a "Y" (for suspended) 
in the space provided f or status code . Add appropriate 
remarks, including reference to the official 
correspondence justifying the cessation of effort. 

f) If the SSD milestone is not the responsibility of the 
organization listed in the responsible organization 
field, note the correct responsible organization, if 
known . 

Late item reports will be generated from the SSD outputs for 
schedule problem identification and resolution. These reports 
will include: 

Reporting date 

Work package identifier 
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Program item number 
Package title 

Responsible organization and supervisor 

Milestone item description 

Schedule source 

Scheduled release date 

Estimated completion date 

Remarks ; 

Reason (for late release) 

Consequence (effect of late release on program) 

Action (required to minimize program inpact) 

The SSD is also the source for the generation of the total 
engineering release status (see fig. 31). 


9.2 ENGINEERING BUDGET TRACKING SYSTEM: JOB STATUS REPORT 

All elements of the engineering cost tracking system should 
be directly related to the WBS (see sec. 4.1). Reports to the 
functional organization should be to WBS levels 4 and 5. Reports 
to program manangement should be summarized to levels 2 and 3. 

Supplemental weekly working reports are submitted via the job 
status (JS) report form (fig. 3 2.), which is a performance- 
reporting element providing a control tool to cost accounting and 
higher-level managers for all direct and overhead work. The 
report is a weekly computer printout of engineering and 
developmental labor budgets, balance-to-complete schedules, and 
expenditures for each cost account by accounting month and 
summarized at task, change, and organizational levels. 


9.2.1 GENERAL INFORMATION 

Approved resource expenditure authorizations are the sources 
for initial budget input data. 
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Figure 31.— Total Engineering Project Design Release Status 
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Figure 32. —Job Status Report 



Primes shall adhere to assigned budgets and shall establish 
and maintain realistic manpower allocations for all committed 
authorized work. Unauthorized anticipated work may be included in 
the Job Status Report, if desired, to reflect potential manpower 
requirements . However, no expenditures may be made against the 
items until authorized. Explanation and illustration of Job 
Status Report entries is given in figure 32. 


9.2.2 REPORTING RESPONSIBILITIES 


9.2.2. 1 Task and Cost Account Managers 

Job status data is reviewed weekly to confirm validity of 
manning plans and completion dates and revise the JS correction 
copy with red pencil as required. Revisions/corrections are 
submitted to engineering costs and schedules. 

Unauthorized committed or anticipated work is entered on the 
JS report as desired for manpower planning or as requested by 
higher management. 


9. 2. 2. 2 Engineering Costs and Schedules 

Assistance is provided to the primes with the initiation of 
and revisions to JS data to ensure that the input is complete and 
accurate . 

The job status report is distributed to appropriate 
supervisors . 

The job status report is analyzed for potential problem areas 
and corrective action (e.g. , budget revision, manning changes, 
completion date revisions, etc.) is recommended. 


9.2.3 JOB STATUS REPORT FORMAT 

The following items describe entries on the job status report 
(see fig. 32.) 

1 . JOB STATUS — the name of the report 

2. Column to identify the horizontal entries as manpower 
expended (EXP) , scheduled (SCH) , or budgeted (BUD) 

3. WORK ITEM IDENTIFICATION — includes identifying numbers 
for work authorized 



4. CHARGE NUMBER — includes the work type code, account 
number, package identifier, and item or serial number 
assigned for the specific job 

5. SRC — special requirements code: a three-character entry 
of one alpha and two alphanumeric combinations 
identifying the business code {e„g., authorized by basic 
contract, authorized by firm change order (CO) for which 
hours have been negotiated, authorized by firm CO but 
not negotiated, committed but unauthorized, etc.) and 
the applicable contract. This code is used primarily 
for machine-sorting for summarization of program data. 

6. JOB — job number: the machine address used to store 
budget, expenditure, and schedule information and to 
collect labor hours and dollars charged to this item on 
employee time record. 

7. EXPENDED FOR WEEK NUMBER — manhours and equivalent men 
expended on this job during the week covered by the 
report. The three-position numerical code is used for 
machine processing purposes to identify the week covered 
by the report. 

u 

8. ADJ — those hours adjusted into or out of cumulative 
expenditures during the week to correct charging errors 
or other erroneous information contained in previous 
reports 

9. CUM EXP — cumulative expenditures: the total manhours and 
equivalent manmonths expended through the current report 
date 

10. FCST REM — forecast remaining: the total scheduled 
manhours and equivalent manmonths remaining until 
completion of the job 

11. EAC — estimate at completion: total planned effort at 
completion in manhours and equivalent manmonths. It 
constitutes expenditures to date plus forecast of 
remaining effort. 

12. BUDGET — budget in terms of manhours and equivalent 
manmonths as authorized by implementing farm. Budget 
cannot be changed without approved revision of 
implementing form. 

13. START — date on which job was scheduled to begin 

14. COMPL — completion date now planned per latest schedule 

15. COMTD — original completion date cortmitted 
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16 . 


EAC — percent of EAC hours that have been expended 
through current report date 

17. M — manual schedule indicating that scheduled inanition ths 
represent a direct month-by -month input 

18. GAL — percent of calendar time between start date and 
completion date that has elapsed through current report 
date 

19. EXC — exception signal. The following exception signals 
may appear in this space, each indicating a situation 
which should be given attention: 

OVERRUN — total planned exceeds budget by 200 hours 
or 25 percent (whichever is smaller) 

UNDERRUN — total planned is less than budget by 200 
hours or 25 percent (whichever is smaller) 

NO START — past start date with no expenditure to 
date 

PAST DUE — job still open beyond completion date 

SCHEDULE — no schedule has been provided for the 
item 

INACTIVE — job number has been closed 

20. PE — past manpower expenditures (cum manmonths) : not 
reflected on the expenditures lines 

21 . PS — past manning schedule (cum manmonths) : not reflected 
on the schedules lines 

22. PB — past budget (cum manmonths) : not reflected on the 
budget lines 

23. Current year expenditures in equivalent manmonths 

24. Current and future years* manning schedule in equivalent 
manmonths 

25. Current and future years* budget in equivalent manmonths 

26. 4 of 5 — indicates the accounting week of the month being 
reported, the fourth week of a four-week month. Since 
March, June, September, and December each contain five 
accounting weeks, reports during these months shall 
carry "x of 5" in this space. 
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27. TOTAL — total expended, total budgeted, and total 
scheduled equivalent manmonths for all jobs previously 
listed. This entry appears near the bottom of the last 
page for the group. 

28. PERCENT — the percent of the organization’s EAC nanhours 
that have been expended to date 

29- ORGN — the group level number of the organization covered 
by the report 
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10.0 PROGRAM VISIBILITY 

Normal display of management information will be accomplished 
by automated preformatted displays of data. This will provide 
management with the capability to review plans, schedules, and 
costs. The plans will outline the sequence of design and analysis 
required at each step. As the design progresses, the plans will 
be updated to show the completion of each step. This will provide 
management with well-supported capability to track the costs, such 
as design engineering and development cost, and estimates of the 
production cost, product support cost, and product operation cost. 
Manual displays will also be used. As time permits, all data for 
the reports described in previous sections and the permanent 
displays shown in section 10.1 should be interfaced with data 
storage and retrieval systems, and a display format should be 
developed accordingly. 


10.1 VISIBILITY ROOM 

The program visibility room is the focal point of program 
control, information, and activity. The information displayed in 
the room must be designed to assist in accomplishing the 
management task. This entails: 

Selection of the proper indices and parameters to measure and 
display 

Clear presentation of the information 
Satisfactory physical equipment to view the data 
Timely maintenance 
Regular use of the room 

Some managers require different types of reports or depend on 
different parameters to indicate program status, therefore, the 
data displayed is tailored to the desires of the managers. It may 
be designed to utilize the concept of management by exception, by 
emphasizing "critical" or "problem" areas in the displays. 

The primary use of a visibility room is a meeting place for 
program reviews, meetings with customers, and other large meetings 
as can be accommodated with the accessibility of the displays. 
Display boards are provided for individual departments to maintain 
runctional data such that departmental meetings may also be held 
in the room as the schedule permits. However, the arrangement of 
the room is such as to emphasize "top-down" program control, with 
summary program information displayed most prominently and first- 
level backup data easily accessible. 
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Management information is accessed and displayed using the 
latest information from the data storage and retrieval system. As 
computer technology advances, the current practice of display 
boards, viewgraphs, etc., can be replaced with large-screen 
display devices that project pr e f or matt ed displays from the data 
storage and retrieval system. 

Careful arrangement of facilities is required to achieve the 
best utilization of the visibility room. There can be different 
arrangements of visibility rooms dependent on the program, budget, 
space, and management requirements. One example of a suitable 
room is shown in figure 33. 

Two banks of 5* x 8* translucent, back -lighted plastic 
sliding boards are provided. Boards are removable so that they 
can be in work outside the visibility room while the room is in 
use. The adjacent work room contains displays in work, inactive 
displays, storage, and a camera to allow rapid availability of 
copies of any display at any time . 


10.2 VISIBILITY DISPLAYS 

Management information display data will be accessed through 
terminals using the latest information from the data storage and 
retrieval system in pre-established format. Types of data to be 
displayed are ; 

General : 

Three -view drawing 
Organization chart 
Management systems flew charts 
Program status : 

WBS/cost control matrix 
Program schedules and status 
Program cost status 
Manpower forecasts and actuals 
Problem item suimiaries 
Action Items 
Functional Status: 
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Backup data and functional organization requirements 


Typical formats for some of these displays are shown in 
figures 34 through 37. 




Figure 33.— Visibility Room Layout 
u> 








©s©©©©®©® ©©©©©©©©© ©©©©©©©©® 


-Cr 


WIND TUNNEL OCCUPANCY HOURS 



PART CARD COUNT 



NORMAL TAKEOFF 


4 


4 


MANAGEMENT ESTIMATE AT COMPLETION MATERIEL COST PERFORMANCE SALES PRICE PRODUCTION UNIT 



LIFT/DRAG RATIO OPERATING WEIGHT PAYLOAD DEMONSTRATION CAPABILITY 



ASSAULT TAKEOFF NORMAL LANDING ASSAULT LANDING 



Figure 34.— Key Performance Tracking Parameters Preliminary Design Period 
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Figure 35.— Key Performance Tracking Parameters, Design Period 





















11.0 CONCLUSIONS 


Systems used to manage a product program are not unique 
within the aerospace industry and are tailored by each company to 
suit its needs. It is concluded that the system described in this 
document should not be implemented into IPAD. However, cost and 
schedule data should be collected relative to use of the IPAD 
system and it should be possible for each company to interface or 
integrate its management systems with the IPAD system. 
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APPENDIX A 


GLOSSARY 


Configuration management 

Continuous process of defining, identifying, and controlling 
baseline product configuration at all design phases 
(conceptual, preliminary, and detail) and at the program f s 
production phase. 

Design-to-cost 

Formal design discipline involving the establishment of 
product cost goals prior to detail design commitment and the 
application of specific management principles to achieve such 
goals through all phases of the product life cycle . 

Job status report 

A weekly computer report of program performance data to cost 
accounting and management for all direct and overhead work. 

Life-cycle costs 

Accurate, predictable costs of the product during its life 
cycle from acquisition through replacement based on estimates 
updated throughout product design phases. 

Program item number (PIN) 

A number that relates an item of work to the work breakdown 
structure, used as a primary index to work items and for cost 
collection. 

Schedule management 

A hierarchical schedule system controlling a master baseline 
schedule and related detail schedules with provision to 
compensate for variances. 

Work breakdown structure (WBS) 

A structured index to all elements of work and all end items 
produced by a product program. 
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APPENDIX B 

SI-U.S. CONVERSION TABLE 


METRIC TABLES 
LENGTH 


Myriameter . 
Kilometer . . 
Hectometer . 
Dekameter. . 


10.000 meters . 

1 .000 meters. . 
100 meters. . . 
1 0 meters . . . 


6.2137 miles. 
0.62137 mile. 
328 feet 1 inch. 
393.7 inches. 


Meter .... 
Decimeter . 
Centimeter. 
Millimeter . 


1 meter 

0.1 meter. . . . 
0.01 meter. . . 
0.001 meter . . 


39.37 inches. 
3.937 inches. 
0.3937 inch. 
0.0394 inch. 


AREA 


Hectare 

Are 

Centiare 


1 0,000 square meters .... 

1 00 square meters 

1 square meter 

2.471 acres. 

1 19.6 square yards. 

1 ,550 square inches. 

WEIGHT 

Name 

Number of 
grams 

Volume corresponding 
to weight 

Avoirdupois 

weight 

Metric ton, millier or tonneau 

Quintal 

Myriagram 

Kilogram or kilo 

Hectogram 

Dekagram 

Gram 

Decigram 

Centigram 

Milligram ^ 

1,000,000 

100,000 

10,000 

1,000 

100 

10 

1 

.1 

.01 

.001 

1 cubic meter . . . . 

1 hectoliter 

1 dekaliter 

1 liter 

1 deciliter 

10 cubic centimeters 
1 cubic centimeter . 
0.1 cubic centimeter 
10 cubic millimeters 
1 cubic millimeter. . 

. 2.204.6 pounds. 
. 220.46 pounds. 

. 22.046 pounds. 

. 2.2046 pounds. 

. 3.5274 ounces. 

; . 0.3527 ounces. 

. 15.432 grains. 

. 1 .5432 grains. 

. 0.1543 grajn. 

. 0.0154 grain. 


CAPACITY 


Name 

Number of 
liters 

Metric cubic 
measure 

United States 
measure 

British measure 

Kiloliter or stere. 

1,000 

1 cubic meter 

1.308 cubic yards 

1.308 cubic yards. 

Hectoliter . . . . 

100 

0.1 cubic meter .... 

. 2.838 bushels; 26.417 gal- 

lons. 

2.75 bushels; 22.00 gal- 
lons. 

Dekaliter 

10 

10 cubic decimeters. . 

. 1.135 pecks; 2.6417 gal- 

lons. 

8.80 quarts; 2.200 gal- 
lons. 

Liter 

1 

1 cubic decimeter . . . 

0.908 dry quart; 1.0567 
liquid quarts. 

0.880 quart. 

Deciliter 

.1 

0.1 cubic decime- 
ter. 

6.1023 cubic inches; 0.845 
gill. 

0.704 gill. 

Centiliter 

.01 

10 cubic centime- 
ters. 

0.6102 cubic inch; 0.338 
fluid ounce. 

0.352 fluid ounce. 

Milliliter 

.001 

1 cubic centimeter . . 

0.061 cubic inch; 0.271 
fluid dram. 

0.284 fluid dram. 


COMMON MEASURES AND THEIR METRIC EQUIVALENTS 


Common measure 


Equivalent 


Common measure Equivalent 


Inch : 2.54 centimeters. 

Foot 0.3048 meter. 

Yard 0.9144 meter. 

Rod 5.029 meters. 

Mile 1 .6093 kilometers. 

Square inch 6.452 square centimeters. 

Square foot 0.0929 square meter. 

Square yard 0.836 square meter. 

Square rod 25.29 square meters. 

Acre 0.4047 hectare. 

Square mile 259 hectares. 

Cubic inch 16.39 cubic centimeters. 

Cubic foot . . . 0.0283 cubic meter. 

Cubic yard 0.7646 cubic meter. 

Cord 3.625 steres. 


Liquid quart. United States . 0.9463 liter. 


Dry quart. United States . . . 1.101 liters. 

Quart, imperial 1.136 liters. 

Gallon, United States 3.785 liters. 

Gallon, imperial 4.546 liters. 

Peck, United States 8.810 liters. 

Peck, imperial 9.092 liters. 

Bushel, United States 35.24 liters. 

Bushel, imperial 36.37 liters. 

Ounce, avoirdupois 28.35 grams. 

Pound, avoirdupois 0.4536 kilogram. 

Ton, long 1 .0160 metric tons. 

Ton, short 0.9072 metric ton. 

Grain . : 0.0648 gram. 

Ounce, troy 31.103 grams. 

Pound, troy 0.3732 kilogram. 
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